A communication network is a network for providing a plurality of users with a number of services. For instance, a communication network may be either a fixed telephone network or a mobile telephone network offering voice services (calls, conference calls, automatic answering service, or the like), or a data network offering data services (e-mail, e-commerce, or the like). A user is connected to the communication network through a terminal, allowing the user to access services.
In a communication network, a service is typically implemented on a client-server basis, wherein server role is played by network apparatuses which are termed “application servers”, whilst client role is played by user terminals. For providing a given service, an application server typically executes a server side service application. On the other hand, for accessing a service, a terminal typically executes a client side service application, which is suitably deployed for interacting with the server side service application relating to that service.
In the following description and in the claims, the term “service application” will indifferently refer both to a server side service application and to a client side service application relating to a given service.
Different methods are known in the art for implementing a service application. For instance, it is known to provide application servers with a service logic execution environment (briefly, SLEE). Such a SLEE is typically stored at an application server, and it is adapted to execute service applications allowing to provide network users with a plurality of services.
More particularly, the specification JSLEE v1.1 EDR, Dec. 21, 2004, details a SLEE in the Java language, which is particularly suitable for executing event based service and to integrate different network resources. Such a SLEE is based on a component-based model, allowing to build each service application as a set of object-oriented components, which are termed “Service Building Blocks” (briefly, SBB components). According to the above JSLEE v1.1, an SBB component identifies the event types accepted by the SBB component and has event handler methods that contain application code that processes events of these event types. In addition, an SBB component may have an interface for synchronous method invocation. At runtime, the SLEE creates instances of these components to process events and deletes components that are no longer eligible for event processing.
A SLEE which is compliant with the above JSLEE v1.1 specification thus comprises a plurality of modules, such as:                a component container for containing SBB components of different service applications;        an event router, whose role will be explained in detail herein after; and        at least a resource adaptor (one resource adaptor for each protocol supported by the communication network), for forwarding information coming from the network and addressed to the SLEE and vice versa.        
A SLEE comprises further modules, which will not be described, since they are not relevant to the present description.
Each SBB component is adapted to receive and process a predefined set of events. An event may comprise either a status change or something occurring either externally or internally to the SLEE. For instance, an event may comprise the reception of a message from the network at the SLEE, based on a given protocol (for instance SIP, http, or others). Alternatively, an event may comprise the expiration of a timer comprised into the SLEE. Generally, events may be generated by the network and received by the SLEE through a suitable resource adaptor. Alternatively, events may be generated by the SBB components, as well as by other modules comprised into the SLEE.
According to the JSLEE v1.1, an event is associated to a number of event variables, such as:                Address: it identifies the address associated to the event (for instance, a telephone number, a URL address, or the like). The type of address varies according to the event type (see below) and according to the resource adaptor which generated such an event (for instance, in case of transmission of a SMS message, the address associated to the event “reception of a SMS message” may be either the sender identifier or the receiver identifier);        AddressProfile: it identifies a service profile associated to the event address identified by the event variable Address. For instance, in the above example of a SMS message transmission, in case the variable Address comprises the sender identifier, the AddressProfile may comprise additional information about the sender, such as terminal type, subscription type, or the like;        ActivityContext: it identifies the activity context the event has been fired on. An activity context, according to the JSLEE v1.1, is basically a logic entity of the SLEE, which is adapted to make a number of attributes available, so that different SBB components can share them (i.e. they can both read them and modify them). An activity context substantially acts as an event addressing point, i.e. it is adapted to receive events and to forward them to SBB components attached to it. An SBB component may be attached to an activity context either by the SLEE, or by the SBB component itself. An event is associated to a single activity context. Such an event may be forwarded only to the SBB components attached to its associated activity context; and        EventType: it identifies the event type. Typically each protocol dependent message is mapped to a specific event type. Events that cause the SLEE to start a new service execution are known as “initial events”.        
JSLEE also provides null activity contexts, which are associated to an active service instance. Trigger events are fired on null activity context. The null activity context allows communication between SBB attached to a same activity.
As the SLEE receives an event and the associated event variables, the event router processes the event variables, and it consequently forwards the received event to the SBB components adapted to receive such an event.
According to JSLEE v1.1, initial events can be declared only by a particular type of SBB components, which are termed “SBB root components”. In particular, as it is known, routing initial events to a suitable SBB root component is performed by the event router by computing a so-called “convergence name”.
The SBB root component has a different convergence name for each initial event it is adapted to receive. Therefore, it is possible to define filtering criteria of initial events received by the SLEE. For instance, based on the convergence name, it is possible to route to an SBB root component only initial events relating to a service provided to a given user associated to a given value of the variable Address. Similarly, it is possible to route to an SBB root component only initial events relating to a service associated to a given activity context.
As already mentioned, SBB root components are adapted to receive initial events. Therefore, they may be directly invoked by the SLEE when a new activity is created associated to the initial event. On the other hand, SBB non-root components are adapted to receive only non-initial events, and therefore they cannot be invoked by the SLEE when an initial event is received and a new activity is created.
According to JSLEE v 1.1, instances to different SBB components (either root or non-root) while executing a service application may be represented as a so-called “SBB entity tree”. An SBB entity is defined as an instance to an SBB component. An SBB entity tree is a tree diagram representing relations between different SBB entities. In particular, the tree root is an instance to an SBB root component of the service, which is termed “SBB root entity”. Each node of such an SBB entity tree represents a respective SBB entity. When a first SBB entity is adapted to generate a second SBB entity, such SBB entities are directly linked by a branch, so that the second SBB entity is downstream the first SBB entity. Different SBB entities may be instances to a same SBB component.
Therefore, according to JSLEE v 1.1, when developing a new service application, SBB root components must be selected and initial event filtering criteria must be provided by defining a rule for computing a convergence name for each SBB root component. Then, the other SBB components are selected, and relations between such components are defined, so that the service application may be represented as an SBB entity tree. Such relations between different SBB components are written in a so-called SBB deployment descriptor, which comprises the SBB's interfaces, classes, child relations, and ActivityContext attribute aliases.
Other types of service logic execution environment are known in the art. US 2002/0191772 discloses a SLEE which is based on the above mentioned specification JSLEE, and which is aimed to make JSLEEs more suitable for real time applications, to reduce complexity of JSLEEs and to allow communication between different service components. To this purpose, US 2002/0191772 discloses a SLEE including a class loader for loading service components in the SLEE, and an event routing bus for receiving events from the protocol layer and other service components. The SLEE can register each loaded service component to receive events directed to particular registered service components. Subsequently, the event routing bus can route received events to the particular registered service component executing in the SLEE. The event routing bus can be further configured to receive events from the application components which are external to the SLEE and the protocol layer.
U.S. Pat. No. 6,690,782 discloses a service logic execution environment, which is namely a JSLEE, which is aimed to make a JSLEE capable of communicating with the protocol stacks in the protocol layer, without requiring specific knowledge of the underlying protocol stack. To this purpose, U.S. Pat. No. 6,690,782 discloses an application execution environment including a SLEE, at least one client component wrapper providing an abstract interface for a specific client component and at least a connector corresponding to the at least one client component, wherein the connector is configured to communicate with a client component through an abstracted interface provided by the corresponding client wrapper.